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Abstract 

Maximizing  local  autonomy  has  led  to  a  scalable  Inter¬ 
net.  Scalability  and  the  capacity  for  distributed  control 
have  unfortunately  not  extended  well  to  resource  access 
control  policies  and  mechanisms.  Yet  management  of 
security  is  becoming  an  increasingly  challenging  prob¬ 
lem,  in  no  small  part  due  to  scaling  up  of  measures  such 
as  number  of  users,  protocols,  applications,  network  el¬ 
ements,  topological  constraints,  and  functionality  expec¬ 
tations. 

In  this  paper  we  discuss  scalability  challenges  for  tra¬ 
ditional  access  control  mechanisms  and  present  a  set  of 
fundamental  requirements  for  authorization  services  in 
large  scale  networks.  We  show  why  existing  mechanisms 
fail  to  meet  these  requirements,  and  investigate  the  cur¬ 
rent  design  options  for  a  scalable  access  control  architec¬ 
ture. 

We  argue  that  the  key  design  options  to  achieve  scala¬ 
bility  are  the  choice  of  the  representation  of  access  con¬ 
trol  policy,  the  distribution  mechanism  for  policy  and  the 
choice  of  access  rights  revocation  scheme. 

1  Introduction 

Technology  trends  and  rapid  commercialization  have 
resulted  in  the  rapid  deployment  of  many  intercon¬ 
nected,  non-research  computer  networks,  particularly 
those  based  on  Internet  technologies  [19,  23].  So- 
called  “network  effects”  apply  strongly  here,  as  increas¬ 
ing  numbers  of  online  services  attract  increasing  num¬ 
bers  of  users  (including  corporate  entities),  attracting  fur¬ 
ther  online  availability  of  information  and  services.  The 
resulting  communications  system  has  large  scale  in  ev¬ 
ery  dimension,  with  large  numbers  of  network-attached 
devices  and  users,  and  a  variety  of  protocols  and  mech- 
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Figure  1 :  A  firewall’s  bottleneck  topology. 

anisms1.  While  users  desire  access  to  as  wide  a  va¬ 
riety  of  data  and  services  as  possible,  some  organiza¬ 
tions  (e.g.,  financial,  military,  etc.)  have  networked  re¬ 
sources  with  more  restrictive  access  control  policies,  and 
various  protection  mechanisms  in  place  to  enforce  these 
policies.  Since  the  same  types  of  equipment  and  proto¬ 
cols/applications  are  used  in  both  “public”  and  “private” 
networks  (those  not  directly  connected  to  the  Internet), 
the  same,  or  very  similar,  security  mechanisms  are  em¬ 
ployed. 

For  example,  IP  firewalls  offer  a  convenient  method 
for  performing  access  control  on  packets  and  connec¬ 
tions  due  to  the  restrictions  they  impose  on  the  network 
topology,  as  seen  in  Figure  1 .  Firewalls  do  not  directly 
enforce  end-to-end  security  properties;  they  are  systems 
dedicated  to  examining  network  traffic  between  a  pro¬ 
tected  network  and  the  rest  of  the  world.  Thus,  a  firewall 
can  permit  or  deny  a  particular  packet  (or  connection) 

1  An  indication  of  the  number  of  new  services  and  protocols  being 
deployed  can  be  found  in  the  number  of  new  Request  For  Comment 
documents  that  have  been  issued  the  past  few  years[20]:  1992  -  92 
RFCs,  1993  -  173,  1994  -  184,  1995  -  130,  1996  -  171,  1997  -  190, 
1998  -  235,  1999  -  260,  2000  -  278.  Not  all  of  these  documents  refer 
to  distinct  protocols  or  services,  but  they  extend  or  modify  existing 
protocols  in  some  way. 
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to  pass  through  it  based  on  a  policy,  but  cannot  directly 
protect  traffic  from  eavesdropping  or  modification  once  it 
has  passed.  Network-layer  encryption  offers  end-to-end 
secrecy  and  integrity  guarantees,  but  does  not  directly 
address  the  issue  of  access  control. 

Network  structure  has  become  sufficiently  complex 
that  building  blocks  such  as  boundary  controllers  and 
encryption  are  increasingly  challenged.  Consider,  for 
example,  “intranets”  and  “extranets”,  where  parts  of  an 
otherwise  protected  network  are  exposed  to  another  en¬ 
tity  for  the  purposes  of  collaboration,  tele-commuting, 
etc.  These  network  structures  need  access  control  mech¬ 
anisms  that  can  operate  throughout  a  network,  and  en¬ 
force  a  coherent  security  policy.  If  we  reexamine  the  use 
of  centralized  firewalls,  we  see  several  problems: 

•  The  assumption  that  all  insiders  are  trusted  is  false. 

•  It  is  easy  for  anyone  to  establish  a  new,  unautho¬ 
rized  entry  point  to  the  network  using  tunnels  or 
poorly  administered  access  points,  such  as  the  in¬ 
creasingly  pervasive  802.11  wireless  access. 

•  Some  protocols  (FTP,  RealAudio)  require  semantic 
knowledge  and  demultiplexing  which  is  hard  to  per¬ 
form  at  a  firewall,  while  application-specific  gate¬ 
ways  are  clumsy  and  introduce  new  sources  of  com¬ 
plexity. 

•  End-to-end  encryption  can  also  be  a  threat  to  fire¬ 
wall  functionality  [2],  as  it  inhibits  examining 
packet  fields  needed  for  filtering. 

•  Finally,  finer- grained  (and  even  application- 
specific)  access  control,  which  standard  firewalls 
cannot  easily  accommodate  within  their  processing 
budget,  is  increasingly  a  requirement. 

1.1  Middleboxes  and  endpoints 

These  problems  suggest  that  access  control  must  become 
an  end-to-end  consideration,  similar  to  authentication 
and  confidentiality.  This  is  not  surprising,  as  the  IP  ar¬ 
chitecture  used  the  end-to-end  argument  [22,  8]  as  the 
basis  for  many  design  decisions.  In  the  present  context, 
we  might  view  the  logical  end  point  (for  access  control) 
as  moving  from  a  centralized  firewall  to  end  nodes  (e.g., 
hosts)  when  a  network  must  support  a  high  degree  of  de¬ 
centralized  access  control. 

To  manage  access  control  in  these  networks  and  de¬ 
liver  the  required  services,  new  tools  and  architectures 
are  needed  to  cope  with  the  increased  scale  and  com¬ 
plexity  of  the  network  entities  (devices,  users,  protocols. 


security  policy  enforcement  points)  and  their  respective 
policies  for  interaction.  Since  the  primary  method  of  ad¬ 
dressing  scalability  issues  in  networking  (and  other  ar¬ 
eas)  has  been  replication,  we  might  attempt  a  “separa¬ 
tion  of  duty”  structure,  where  different  individuals  man¬ 
age  different  aspects  of  the  network’s  operations.  Un¬ 
fortunately,  current  tools  either  ignore,  or  do  not  suffi¬ 
ciently  address  separation  of  duty  concerns,  as  we  shall 
see  later  in  Section  2.  Even  in  small  networks,  adminis¬ 
trators  have  trouble  handling  the  configuration  of  a  small 
number  of  firewalls  [29].  The  results  of  this  can  be  seen 
in  studies  of  network  intrusions  and  their  causes  [13]: 
an  increasing  number  of  vulnerabilities  can  be  directly 
attributed  to  misconfiguration,  with  an  even  larger  per¬ 
centage  of  intrusions  indirectly  caused  by  administration 
failures. 

1.2  Access  Control  Scalability 

The  situation  is  equivalently  bad  in  simply  scaling  the 
policy  enforcement  mechanisms;  most  access  control 
mechanisms  become  a  bottleneck  as  the  level  of  replica¬ 
tion  increases  in  an  attempt  to  meet  increased  demands 
in  network  bandwidth,  I/O  and  processing.  To  better  il¬ 
lustrate  this,  let  us  consider  a  simple  example. 

Imagine  a  building  with  N  doors.  People  wishing  to 
enter  the  building  show  up  at  one  of  the  door;  all  doors 
are  equivalent  for  the  purpose  of  accessing  the  building. 

In  a  simple  configuration,  each  door  has  a  guard  that 
examines  the  person’s  identification  (authentication)  and 
checks  the  list  of  people  that  are  allowed  to  enter  the 
building  (access  control).  If  the  person  is  on  the  list,  he 
is  allowed  in  the  building. 

To  scale  for  many  visitors,  we  have  to  increase  the 
number  of  doors.  In  the  case  of  the  traditional  access 
control  (using  guards),  we  have  the  problem  of  distribut¬ 
ing  the  list  to  all  the  guards  and  maintaining  that  list.  Fur¬ 
thermore,  if  the  number  of  potential  visitors  is  large,  the 
list  becomes  very  large  and  the  guards  have  to  spend  time 
and  effort  looking  up  people  in  that  list  (let  alone  lifting 
the  book!).  Although  we  have  multiple  doors,  and  we 
can  hire  many  guards,  the  work  of  the  guards  increases 
rapidly  with  the  number  of  users,  because  that  work  de¬ 
pends  on  the  size  of  the  list. 

Now  consider  a  scenario  where  the  guards  are  replaced 
with  locks  on  the  doors.  Each  person  has  a  key  and  that 
key  grants  access  to  the  building.  Let  us  assume  momen¬ 
tarily  that  all  visitors  have  the  same  key  (access  control 
policy);  in  that  case,  any  visitor  can  enter  through  any 
door.  The  work  in  performing  an  access  control  decision 
does  not  depend  on  the  number  of  doors.  Also  since  each 
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visitor  is  supplying  the  key,  the  complexity  of  the  locks 
on  each  door  is  independent  of  the  total  number  of  visi¬ 
tors  or  the  number  of  other  doors.  As  the  complexity  of 
the  mechanism  increases  (more  sophisticated  locks,  tak¬ 
ing  more  time  to  operate)  the  throughput  per  door  may 
go  down,  but  this  can  be  fixed  by  adding  more  doors. 

We  shall  see  in  a  later  section  how  the  problem  of  giv¬ 
ing  all  the  visitors  the  same  key  can  be  addressed. 

1.3  Organization 

The  rest  of  the  paper  is  organized  as  follows.  Section 
2  outlines  requirements  for  modern  networks  and  points 
out  where  current  systems  are  inadequate  to  meet  these 
requirements.  Section  3  discusses  the  various  options 
available  to  the  designer  of  an  access  control  mechanism, 
with  particular  emphasis  to  a  credential-based  system. 
Section  4  concludes  the  paper  with  a  brief  summary  of 
what  should  be  “ideal”  access  control  scheme  for  a  large 
multi-service  network  infrastructure. 

2  New  requirements  and  existing 
architectures 

Access  control  management  systems  appropriate  for  the 
scale  and  complexity  of  today’s  networks  must  meet  sev¬ 
eral  requirements: 

1.  The  system  must  be  able  to  support  the  security  pol¬ 
icy  requirements  of  many  diverse  applications,  given  the 
large  number  in  use  today.  (The  term  “applications” 
is  used  to  mean  services  and  protocols  that  require  ac¬ 
cess  control  configuration.  These  applications  can  be 
security-oriented,  e.g.,  a  network  layer  security  protocol, 
or  they  may  be  consumers  of  security  services,  e.g.,  a 
web  server.) 

2.  The  increasing  size  and  complexity  of  networks 
strains  the  ability  of  administrators  to  effectively  man¬ 
age  their  systems.  The  traditional  way  of  handling  scale 
at  the  human  level  has  been  decentralization  of  manage¬ 
ment  and  delegation  of  authority.  This  approach  is  evi¬ 
dent  throughout  the  complete  range  of  human  activities 
( i.e .,  most,  if  not  all,  effective  large  “systems”  involve  the 
creation  and  maintenance  of  an  administration  service 
where  responsibility  for  different  aspects  of  the  system 
is  handled  by  different  entities).  Thus,  an  access  control 
management  system  for  large  networks  must  be  able  to 
adapt  to  different  management  structures  (web  of  trust, 
hierarchical  management,  etc.). 


3.  The  system  should  be  agnostic  with  respect  to  the 
configuration  front-end  that  administrators  use.  The  first 
reason  for  this  is  to  allow  a  decoupling  of  the  manage¬ 
ment  mechanism,  which  could  potentially  be  used  for  the 
whole  lifetime  of  the  network,  from  the  method  used  to 
configure  it,  which  may  change  as  a  result  of  new  devel¬ 
opments  in  Human-Computer  Interaction  interfaces,  or 
because  of  a  change  in  administrators.  Secondly,  such 
a  system,  by  allowing  the  use  of  different  management 
front-ends  for  configuring  different  applications’  access 
control  policies,  encourages  the  development  and  use  of 
front-ends  (GUIs,  languages,  etc.)  that  are  tailored  to  the 
specific  application  and  its  particular  nuances. 

We  should  note  that  this  requirement  is  not  typical  for 
access  control  management  systems;  most  such  systems 
promote  the  use  of  a  single  configuration  front-end  for 
all  the  applications  in  the  system.  Although  more  re¬ 
search  is  needed  in  this  area,  one  can  see  the  parallels  be¬ 
tween  the  all-encompassing  languages  developed  in  the 
1970s  and  the  more  recent  trend  on  “domain-specific” 
languages  (languages  specifically  designed  to  address  a 
limited  application  domain,  e.g.,  active  networks). 

4.  The  system  must  be  able  to  handle  large  numbers  of 
users,  applications,  and  policy  evaluation  and  enforce¬ 
ment  points.  As  we  saw  above,  corporate  (and  other) 
networks  are  rapidly  increasing  in  size;  furthermore,  new 
protocols  are  being  deployed  (without  necessarily  depre¬ 
cating  old  ones);  finally,  these  same  networks  are  used 
in  increasingly  more  complicated  ways  (intranets,  ex¬ 
tranets,  etc.). 

5.  A  corollary  of  the  above  is  that  the  system  should  be 
able  to  handle  the  common  operations  (such  as  adding 
or  removing  users)  efficiently.  This  is  important  be¬ 
cause,  over  the  lifetime  of  the  system,  these  overheads 
will  dominate  other  costs  like  initial  deployment. 

6.  Last  but  not  least,  the  system  must  be  efficient.  It 
should  not  impose  significant  overheads  on  existing  pro¬ 
tocols  and  mechanisms;  it  should  strive  to  match  the  per¬ 
formance  curve  attained  by  service  replication.  Ideally, 
it  should  even  improve  performance  by  addressing  any 
inefficiencies  in  existing  management  systems. 

2.1  Systems  versus  requirements 

2.1.1  ACLs  and  Taos 

The  work  by  Lampson  [15,  16]  established  the  ground 
rules  for  access  control  policy  specification  by  introduc- 
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ing  the  access  control  matrix  as  a  useful  generalization 
for  modeling  access  control.  A  concept  derived  from  the 
access  control  matrix  that  is  used  in  many  security  sys¬ 
tem  is  the  Access  Control  List  (ACL);  this  is  a  list  of  < 
Subject,  Object,  Access  Rights  >  tuples,  that  collectively 
encompass  the  access  control  policy  of  the  entire  sys¬ 
tem,  in  terms  of  users,  and  services  or  data  to  which  ac¬ 
cess  must  be  controlled.  The  focus  in  both  that  work  and 
in  Taos  [28]  is  on  authentication.  The  latter  depended 
on  a  unified  policy  specification  and  enforcement  frame¬ 
work,  although  it  identified  credentials  (in  the  form  of 
digitally  signed  statements)  as  a  scalable  authorization 
mechanism. 

2.1.2  Policy  algebras 

In  [3]  the  authors  propose  an  algebra  of  security  policies 
that  allows  combination  of  authorization  policies  spec¬ 
ified  in  different  languages  and  issued  by  different  au¬ 
thorities.  The  algebraic  primitives  presented  allow  for 
considerable  flexibility  in  policy  combination.  As  the  au¬ 
thors  discuss,  their  algebra  can  be  directly  translated  to 
boolean  predicates  that  combine  the  authorization  results 
of  the  different  policy  engines.  The  main  disadvantage 
of  this  approach  is  that  it  assumes  that  all  policies  and 
(more  importantly)  all  necessary  supporting  information 
is  available  at  a  single  decision  point,  which  is  a  diffi¬ 
cult  proposition  even  within  the  bounds  of  an  operating 
system.  Our  observation  here  is  that  in  fact  the  decision 
made  by  a  policy  engine  can  be  cached  and  reused  higher 
in  the  stack.  Although  the  authors  briefly  discuss  partial 
evaluation  of  composition  policies,  they  do  so  only  in  the 


context  of  their  generation  and  not  on  enforcement. 

2.1.3  Domain  specific  languages 

The  approach  taken  in  Firmato[l]  is  that  of  use  of  a 
“network  grouping”  language  that  is  customized  for  each 
managed  firewall  at  that  firewall.  The  language  used  is 
independent  of  the  firewalls  and  routers  used,  but  is  lim¬ 
ited  to  packet  filtering.  Furthermore,  it  does  not  han¬ 
dle  delegation,  nor  was  it  designed  to  cover  different,  in¬ 
teracting  application  domains  (IPsec,  web  access,  etc.). 
Policy  updates  are  equivalent  to  policy  initializations  in 
that  they  require  a  reloading  of  all  the  rules  on  the  af¬ 
fected  enforcement  points.  Finally,  the  entire  relevant 
policy  rule-set  has  to  be  available  at  an  enforcement 
point,  causing  scale  problems  with  respect  to  the  number 
of  users,  peer  nodes,  and  policy  entries.  Other  similar 
work  includes  [12,  9,  18]. 

2.1.4  Names  and  role  dependencies 

In  the  OASIS  architecture  [11],  the  designers  identify 
the  dependencies  between  different  services  and  the  need 
to  coordinate  these.  They  present  a  role -based  system 
where  each  principal  may  be  issued  with  a  name  by  one 
service  on  condition  that  it  has  already  been  issued  with 
some  specified  name  of  another  service.  Their  system 
uses  event  notification  to  revoke  names  when  the  issuing 
conditions  are  no  longer  satisfied,  thus  revoking  access  to 
services  that  depended  on  that  name.  Each  service  is  re¬ 
sponsible  for  performing  its  own  authentication  and  pol¬ 
icy  enforcement.  However,  credentials  in  that  system  are 
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limited  to  verifying  membership  to  a  group  or  role,  thus 
making  it  necessary  to  keep  policy  closely  tied  to  the  ob¬ 
jects  it  applies  to.  Furthermore,  OASIS  uses  delegation 
in  a  very  limited  scope,  thus  limiting  administrative  de¬ 
centralization. 

2.1.5  Policy  mediation,  proxying  and  delegation 

The  work  described  in  [10]  proposes  a  ticket-based  ar¬ 
chitecture  using  mediators  to  coordinate  policy  between 
different  information  enclaves.  Policy  relevant  to  an  ob¬ 
ject  is  retrieved  by  a  central  repository  by  the  controlling 
mediator.  Mediators  also  map  foreign  principals  to  local 
entities,  assign  local  proxies  to  act  as  trusted  delegates 
of  foreign  principals,  and  perform  other  authorization- 
related  duties.  Coordination  policy  must  be  explicitly 
defined  by  the  security  administrator  of  a  system,  and  is 
separate  from  (although  is  taken  in  consideration  along 
with)  access  policy. 

2.1.6  Group-based  access  control 

The  Napoleon  system  [24,  25]  defines  a  layered  group- 
based  access  control  scheme  that  is  in  some  ways  similar 
to  the  distributed  firewall  concept  presented  in  [14],  al¬ 
though  it  is  mostly  targeted  to  RMI  environments  like 
CORBA.  Policies  are  compiled  to  access  control  lists  ap¬ 
propriate  for  each  application  (in  our  case,  that  would  be 
each  end  host)  and  pushed  out  to  them  at  policy  creation 
or  update  time. 

2.1.7  Specializing  security  with  wrappers 

SnareWork  [7]  is  a  DCE-based  system  that  can  provide 
transparent  security  services  (including  access  control)  to 
end-applications,  through  use  of  wrapper  modules  that 
understand  the  application-specific  protocols.  Policies 
are  compiled  to  ACLs  and  distributed  to  the  various  hosts 
in  the  secured  network.  Connections  to  protected  ports 
are  reported  to  a  local  security  manager  which  decides 
whether  to  drop,  allow,  or  forward  them  (using  DCE 
RPC)  to  a  remote  host,  based  on  the  ACLs. 

2.1.8  Decentralized  enforcement  and  delegation 

[5]  describes  an  open,  scalable  mechanism  for  enforcing 
security.  It  argues  for  a  shift  to  a  more  decentralized  pol¬ 
icy  specification  and  enforcement  paradigm,  without  dis¬ 
cussing  the  specifics  of  policy  expression.  It  emphasizes 
the  need  for  delegation  as  a  mechanism  to  achieve  scale 
and  decentralization,  but  focuses  on  design  of  protocols 


(1) :  'Hi,  I’m  Client" 

(2) :  Ticket-Granting  Ticket  (TGT) 

(3) :  Client,  Enforcement  Point,  TGT 

(4) :  Service-specific  Ticket  (TKT) 

(5) :  TKT,  request 

Figure  2:  The  Kerberos  authentication  protocol. 

for  accomplishing  this  rather  than  the  more  high-level  re¬ 
quirements  on  policy  expression. 

2.1.9  RAP,  COPS,  RADIUS  and  DIAMETER 

In  the  IETF,  the  RAP  (RS  VP  Admission  Policy)  working 
group  has  defined  the  COPS  [4]  protocol,  as  a  standard 
mechanism  for  moving  policy  to  the  devices.  This  pro¬ 
tocol  was  developed  for  use  in  the  context  of  QoS,  but  is 
general  enough  to  be  used  in  other  application  domains. 

RADIUS  [21]  and  its  proposed  successor,  DIAME¬ 
TER  [6],  are  similar  in  some  ways  to  COPS.  They  require 
communication  with  a  policy  server,  which  is  supplied 
with  all  necessary  information  and  is  depended  upon  to 
make  a  policy-based  decision.  Both  protocols  are  ori¬ 
ented  toward  providing  Accounting,  Authentication,  and 
Authorization  services  for  dial-up  and  roaming  users. 

2.1.10  Kerberos 

Kerberos  [17]  is  an  authentication  system  that  uses  a  cen¬ 
tral  server  and  a  set  of  secret  key  protocols,  as  shown  in 
Figure  2,  to  authenticate  clients  and  give  both  a  client  and 
an  application  server  a  secret  key  for  use  in  protecting 
further  communications.  Initially,  the  client  authentica¬ 
tion  to  the  Key  Distribution  Center  (KDC),  which  gives 
it  a  Ticket  Granting  Ticket;  this  step  occurs  infrequently 
(typically,  once  every  8  hours).  For  each  service  the 
client  needs  to  contact,  it  must  then  contact  the  Ticket 
Granting  Service  (TGS),  which  responds  with  a  Ticket 
(TKT)  that  is  service-specific.  The  client  then  contacts 
the  service,  providing  TKT.  Often,  the  KDC  and  the  TGS 
are  co-located. 
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The  two  most  important  deficiencies  of  Kerberos 
are  that  it  does  not  implement  any  kind  of  authoriza¬ 
tion  (applications  are  expected  to  make  their  own  ac¬ 
cess  control  decisions,  based  on  information  they  ac¬ 
quire  through  other  means,  e.g.,  Directory  Services,  lo¬ 
cal  ACLs,  database  queries),  and  it  is  expensive,  in  terms 
of  administrative  effort,  to  do  cross-realm  authentication, 
as  this  requires  all  clients  to  have  complete  knowledge  of 
the  trust  relationships  between  realms  (a  Kerberos  realm 
is  the  collection  of  systems  and  users  managed  by  a  sin¬ 
gle  administrative  entity).  Although  there  has  been  some 
recent  work  towards  addressing  these  issues  [27,  26], 
there  remain  significant  problems  with  using  Kerberos 
in  a  truly  large  scale  environment. 


A  more  important  deficiency,  however,  lies  in  the  na¬ 
ture  of  the  secret  key  authentication  employed  by  Ker¬ 
beros:  Referrals  (used  for  cross-realm  authentication) 
can  solve  the  problem  of  securely  determining  the  iden¬ 
tity  of  the  principals  and  KDCs  involved  in  a  request, 
but  they  cannot  be  used  to  convey  hierarchical  policy  in¬ 
formation  to  the  enforcement  point,  beyond  any  policy 
included  in  the  ticket  issued  by  the  enforcement  point’s 
KDC.  While  access  policy  could  be  encoded  in  the  re¬ 
ferrals  themselves,  these  would  not  be  verifiable  to  the 
enforcement  point  (since  it  does  not  share  a  secret  key 
with  any  of  the  intermediate  KDCs).  The  intermediate 
KDCs  cannot  make  an  access  control  decision  at  the  time 
the  referral  must  be  issued,  since  they  do  not  have  any 
information  about  the  application  request  itself;  even  if 
they  did,  however,  this  would  be  an  extremely  inefficient 
approach  to  access  control,  since  all  such  KDCs  would 
have  to  be  contacted  each  time  a  request  is  made  —  with 
no  possibility  of  ticket  and  referral  caching,  as  is  cur¬ 
rently  possible. 


Similar  inefficiencies  arise  when  the  enforcement 
point  contacts  each  KDC  for  every  request  made  by  the 
client.  Either  of  these  approaches  effectively  converts 
a  fairly  decentralized  authentication  mechanism  into  an 
extremely  centralized  access  control  mechanism.  Fi¬ 
nally,  a  referral-based  architecture  that  supports  policy 
dissemination,  requires  duplication  of  client  information 
at  both  the  client  and  the  enforcement  point’s  KDC. 
This  is  necessary  because  only  the  enforcement  point’s 
KDC  can  provide  policy  information  to  the  enforcement 
point  (encoded  inside  a  ticket),  and  therefore  has  to  have 
knowledge  of  the  client’s  privileges. 


2.2  Summary:  Access  Control  System 
Classification 

Table  1  classifies  the  various  systems  based  on  the  re¬ 
quirements  we  enumerated.  For  the  real  system  require¬ 
ments  we  enumerated  at  the  beginning  of  this  section,  no 
single  system  gets  right  all  of  the  policy  and  mechanism 
interaction  challenges.  The  next  section  outlines  design 
choices  needed  for  such  a  system. 

3  Designing  a  Scalable  Access  Con¬ 
trol  Architecture 

The  concerns  outlined  in  Section  2  must  guide  the  design 
of  an  access  control  architecture.  Such  a  system  must  ef¬ 
fectively  scale  in  two  different,  but  related,  areas:  system 
and  management  complexity  (and  size). 

Addressing  system  complexity  requires  policy  speci¬ 
fication,  distribution,  and  enforcement  mechanisms  that 
can  handle  large  numbers  of  users,  enforcement  points, 
and  applications.  Furthermore,  the  system  must  be  able 
to  handle  the  increased  complexity  of  mechanism  inter¬ 
actions.  We  can  critique  three  obvious  models  rather  eas¬ 
ily. 

Fully-centralized  (Figure  3)  approaches  demonstrate 
poor  scaling  properties.  Here,  the  enforcement  points 
contact  the  server  with  the  user  request  details,  and  ex¬ 
pect  an  answer.  Policy  evaluation  is  done  at  the  central 
repository,  for  each  request.  Responses  may  be  cached 
at  the  enforcement  points,  as  long  as  the  details  of  the 
request  do  not  change,  but  systems  implementing  this 
approach  must  therefore  also  address  policy  consistency 
issues.  Interactions  between  services  and  protocols  are 
easy  to  define,  since  all  the  information  is  centrally  avail¬ 
able. 

Semi-centralized  (Figure  4)  approaches  are  those 
where  policy  is  centrally  specified  but  distributed  (syn¬ 
chronously,  or  “simultaneously”)  to  all  enforcement 
points.  Interactions  between  protocols  and  services  are 
easy  to  define,  since  all  the  information  is  centrally  avail¬ 
able.  Changes  to  the  running  system  require  commu¬ 
nication  with  the  affected  enforcement  points.  Such 
approaches  require  the  enforcement  points  to  maintain 
large  amounts  of  potentially  unneeded  state,  and  require 
communication  for  common  (and  thus  frequent)  security 
operations  such  as  adding/removing  users  or  modifying 
their  privileges. 
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3.1  Use  of  flexible  credentials 


Central  policy  repository 


Figure  3:  Centralized  policy  specification  and  enforcement. 


Central  policy 
specification 


Figure  4:  Central  policy  specification,  decentralized  en¬ 
forcement. 


Fully-decentralized  (Figure  5)  approaches  do  not  eas¬ 
ily  allow  for  interaction  between  different  applications. 
Policy  is  specified  by  different  administrators  for  the  dif¬ 
ferent  applications,  users,  and  enforcement  points.  Pol¬ 
icy  may  be  distributed  directly  to  the  enforcement  points, 
or  may  be  made  available  to  the  users  in  the  form  of 
certificates  or  tickets.  Interactions  between  protocols 
and  services  are  difficult  to  express,  unless  an  addi¬ 
tional  “coordination”  layer  is  added,  which  re-introduces 
a  measure  of  centralization  to  the  system;  the  coordina¬ 
tion  layer  may  be  explicit  (in  the  form  of  a  meta-policy 
server),  or  implicit  (in  the  form  of  a  meta-policy  lan¬ 
guage). 

No  real  system  follows  any  of  these  three  approaches 
(especially  the  centralized  ones)  in  their  pure  form  ( e.g ., 
caches  are  employed  at  enforcement  points),  but  they 
outline  the  separation  of  policy  from  mechanism  in  ac¬ 
cess  control  architectures. 


As  a  first  design  choice  then,  a  system  should  exhibit  the 
scaling  properties  of  a  decentralized  policy  specification, 
distribution,  and  enforcement  system,  while  retaining  the 
ability  to  let  different  applications  and  protocols  interact 
as  needed.  Therefore,  policy  should  be  expressed  in  a 
way  that  is  easy  to  distribute  to  enforcement  points  “on 
the  fly”,  and  which  is  easy  for  the  enforcement  points 
to  verify  and  process  efficiently.  One  way  of  expressing 
low-level  policy  is  in  the  form  of  public-key  credentials 
(roughly,  public-key  certificates  with  authorization  infor¬ 
mation  embedded  inside  them);  an  administrator  can  is¬ 
sue  signed  statements  that  contain  the  privileges  of  users; 
enforcement  points  can  verify  the  validity  of  these  cre¬ 
dentials  and  enforce  the  policies  encoded  therein.  An 
additional  benefit  is  that,  since  credentials  are  integrity- 
protected  via  a  digital  signature,  they  need  not  be  pro¬ 
tected  when  transmitted  over  the  network  (thus  avoiding 
a  potential  security  bootstrap  problem).  Thus,  it  is  pos¬ 
sible  to  distribute  policies  in  any  of  the  following  three 
ways: 

1.  Have  the  policies  “pushed”  directly  to  the  enforce¬ 
ment  points.  While  this  is  the  simplest  approach,  it  re¬ 
quires  all  policy  information  to  be  stored  locally  at  an 
enforcement  point,  which  may  present  problems  for  em¬ 
bedded  systems  or  routers.  For  example,  assume  a  sys¬ 
tem  that  any  of  100,000  users  may  access;  identifying 
each  user  would  require  knowledge  of  their  public  key, 
for  authentication  purposes.  Assuming  a  typical  RSA 
key  of  128  bytes  (1024  bits),  simply  storing  this  informa¬ 
tion  requires  about  13  MB,  excluding  any  access  control 
information.  Typical  certificate  encodings  multiply  this 
by  3  or  4,  and  access  control  information  will  further  add 
to  this. 

Furthermore,  under  this  scheme,  changes  in  the  policy 
(e.g.,  adding  a  new  user)  require  all  affected  systems  to 
be  contacted  and  their  local  copy  of  the  policy  updated. 
If  such  changes  are  frequent,  or  the  number  of  affected 
systems  is  large,  the  cost  can  prove  prohibitive. 

Finally,  the  enforcement  point  will  also  have  to  incur  a 
processing  cost  for  examining  potentially  “useless”  pol¬ 
icy  entries  when  trying  to  determine  whether  a  specific 
user  request  should  be  granted.  The  exact  cost  depends 
on  the  particular  scheme  used  to  store  and  process  this 
information. 

2.  Have  the  policies  “pulled”  by  the  enforcement  points 
from  a  policy  repository  as  needed,  and  then  stored  lo¬ 
cally.  This  exhibits  much  better  behavior  in  terms  of  pro- 
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Figure  6:  Policy  distribution  models. 


Figure  5:  Decentralized  policy  specification  and  enforce¬ 
ment. 

cessing  and  storage  requirements,  but  requires  that  the 
enforcement  point  perform  some  additional  processing 
(and  incur  some  communication  overhead)  when  evalu¬ 
ating  a  security  request.  System  availability  can  be  ad¬ 
dressed  via  replicated  repositories;  an  attacker  that  com¬ 
promises  one  or  more  of  these  can  deny  service  to  legiti¬ 
mate  users,  but  cannot  otherwise  affect  a  policy  decision. 
This  approach  offers  two  additional  advantages:  first,  it 
is  relatively  easy  to  deploy  since  it  requires  modification 
of  only  the  enforcement  points  (as  opposed  to  modifying 
all  the  clients  and  other  network  elements).  Secondly,  it 
effectively  addresses  privilege  revocation  (which  we  dis¬ 
cuss  later  in  this  section). 

3.  Have  the  policies  distributed  to  the  client  (user)  sys¬ 
tems,  and  make  these  responsible  for  delivering  them  to 
the  enforcement  points.  While  this  approach  requires 
modification  of  the  client,  most  security  protocols  al¬ 
ready  provide  certificate  exchange  as  part  of  the  authen¬ 
tication  mechanism;  it  is  often  relatively  straightforward 
to  modify  such  protocols  to  deliver  the  kind  of  creden¬ 
tials  used  in  our  system  instead.  Furthermore,  since  the 
end  systems  hold  all  the  credentials  that  are  relevant  to 
them,  it  is  possible  to  determine  in  advance  under  what 
conditions  a  request  will  be  granted  by  an  enforcement 
point  ( e.g how  strong  the  encryption  should  be  to  be 
able  to  see  confidential  information  on  the  corporate  web 
server). 

The  three  approaches  to  policy  distribution  are  shown 
in  Figure  6.  These  approaches  are:  (1)  policy  is  pushed 


to  the  enforcement  points;  (2)  policy  is  “pulled”  by  the 
enforcement  points  from  a  repository;  and  (3)  policy  is 
supplied  to  the  end  users  which  must  deliver  it  to  the  en¬ 
forcement  points  as  needed.  A  combination  of  (2)  and 
(3)  may  be  used  in  the  system:  if  the  client  system  pro¬ 
vides  credentials  during  the  authentication  phase,  these 
are  used  to  determine  the  user’s  privileges;  otherwise, 
the  system  may  contact  a  repository  to  retrieve  the  rel¬ 
evant  information  or,  if  it  is  overloaded,  deny  the  request 
and  ask  that  the  user  provide  the  missing  information  in 
a  subsequent  request.  One  advantage  of  this  approach  is 
that  policy  can  be  treated  as  “soft  state,”  and  periodically 
be  purged  to  handle  new  users  and  requests  (using  LRU, 
or  some  other  replacement  mechanism).  If  the  policy  is 
needed  again,  it  will  be  re-instantiated.  This  mechanism 
is  conceptually  similar  to  virtual  memory  page  replace¬ 
ment  algorithms  used  by  modern  operating  systems,  and 
thus  many  such  algorithms  can  be  reused  here  for  pur¬ 
poses  of  policy  state.  We  call  this  mechanism  “lazy  pol¬ 
icy  instantiation”  in  our  context. 

One  benefit  of  choosing  to  use  credentials  as  a 
means  for  distributing  policy  is  the  fact  that  one  of  the 
frequently-done  operations  (adding  a  user,  or  giving  ad¬ 
ditional  privileges  to  an  existing  user)  is  cheap:  we  sim¬ 
ply  have  to  issue  the  necessary  credentials  for  the  user 
in  question,  and  make  them  available  in  the  repository. 
Under  any  of  the  distribution  schemes  already  described, 
the  new  policy  will  take  effect  as  soon  as  the  next  request 
that  requires  is  appears. 

On  the  other  hand,  one  other  frequent  operation  (re¬ 
moving  a  user,  or  revoking  some  existing  user’s  privi¬ 
leges)  is  more  complicated  in  an  environment  where  pol¬ 
icy  is  not  centrally  stored  and  maintained.  We  defer  dis¬ 
cussion  of  this  issue  until  Section  3.4. 
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Figure  7:  Different  combinations  of  policy  specification 
and  decision  making  with  respect  to  (de)centralization. 


3.2  Ease  of  administration 

The  second  scale-related  problem  area  our  system  must 
address  is  administrative  complexity;  the  increased  sys¬ 
tem  scale  stretches  the  ability  of  human  administrators 
to  handle  its  complexity.  One  well-known  and  widely 
used  solution  is  that  of  “separation  of  duty”:  different 
administrators  are  made  responsible  for  managing  dif¬ 
ferent  aspects  of  the  larger  system.  In  computer  net¬ 
works,  this  separation  can  be  implemented  across  net¬ 
work  boundaries  (e.g.,  LAN  or  WAN  administrators)  or 
across  application  boundaries  (e.g.,  different  administra¬ 
tors  for  the  firewalls,  the  web  servers,  the  print  servers, 
etc.).  Multiple  layers  of  management  may  be  used,  to 
handle  increasing  scale.  Thus,  our  system  must  support 
this  management  approach.  One  commonly-used  mech¬ 
anism  that  implements  hierarchical  management  in  de¬ 
centralized  systems  is  delegation  of  authority. 

Note  that  the  degree  of  (de)centralization  of  policy 
specification  and  enforcement  are  independent  of  each 
other:  decentralized  policy  specification  may  be  built  on 
top  of  a  centralized  enforcement  system,  by  providing 
a  suitable  interface  to  the  different  administrators;  simi¬ 
larly,  a  centralized  policy  specification  system  can  easily 
be  built  on  top  of  decentralized  enforcement  architecture, 
as  shown  in  Figure  7.  Although  the  actual  enforcement  is 
done  at  the  different  network  elements  (marked  as  “en¬ 
forcement  points”),  enforcement  typically  refers  to  the 
decision  making  (policy  evaluation). 


Figure  8:  A  multi-layer  access  control  architecture. 

3.3  Layering  considerations 

These  considerations  argue  for  a  multi-layer  design,  such 
as  shown  in  Figure  8.  Administrators  can  use  any  num¬ 
ber  of  different  interfaces  in  specifying  access  control 
policy.  Thus,  administrators  can  pick  an  interface  they 
are  already  familiar  with  or  one  that  is  not  very  different 
from  what  they  have  been  using.  Furthermore,  it  is  possi¬ 
ble  to  construct  application-specific  interfaces,  that  cap¬ 
ture  the  particular  nuances  of  the  application  they  con¬ 
trol.  This  architecture  has  an  intentional  resemblance  to 
the  IP  “hourglass”,  and  resolves  heterogeneity  in  simi¬ 
lar  ways,  e.g.,  the  mapping  of  the  interoperability  layer 
onto  a  particular  enforcement  device,  or  the  servicing  of 
multiple  applications  with  a  policy  lingua  franca. 

Is  is  important  to  realize  that  the  design  in  Figure  8 
refers  to  the  logical  flow  of  policy;  the  system  itself 
follows  the  decentralized  policy  specification  and  en¬ 
forcement  approach.  High-level  policy  is  specified  sepa¬ 
rately  by  each  administrator.  This  interface  takes  as  input 
the  stated  policy  and  information  from  a  network/user 
database,  and  produces  policy  statements  in  the  common 
language  of  the  low-level  policy  system.  Thus,  the  low- 
level  policy  system  (the  policy  interoperability  layer,  as 
it  were)  must  be  powerful  and  flexible  enough  to  han¬ 
dle  different  applications.  These  low-level  policy  state¬ 
ments  are  then  distributed  on-demand  to  the  enforcement 
points,  where  policy  evaluation  and  enforcement  is  per¬ 
formed  locally. 

To  accommodate  management  delegation,  one  of  two 
approaches  may  be  taken:  delegation  may  be  imple¬ 
mented  as  part  of  the  low-level  policy  mechanism,  or  as 
a  function  of  the  high-level  policy  specification  system. 
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Figure  10:  Delegation  as  part  of  the  low-level  policy  system. 


Figure  9:  Delegation  as  a  function  of  high-level  policy  spec¬ 
ification. 

as  shown  in  Figures  9  and  10.  We  differentiate  between 
high  and  low  levels  in  the  following  way.  High-level  pol¬ 
icy  statements  by  different  administrators  at  level  N  of 
the  management  hierarchy  are  imported  and  combined  at 
level  N-l,  recursively.  The  top-level  administrator  pro¬ 
duces  the  final  low-level  policy  statement,  as  a  result  of 
the  composition  of  all  the  policies.  In  contrast,  low-level 
policy  statements  from  all  (relevant)  administrators  are 
combined  at  the  policy  evaluation  point. 

The  high-level  approach  offers  considerable  flexibil¬ 
ity  in  expressing  delegation  and  related  restrictions,  but 
causes  the  higher  echelons  of  the  administrative  hierar¬ 
chy  to  become  bottlenecks,  since  they  have  to  be  in¬ 
volved  in  all  policy  specification.  One  advantage  of  fol¬ 
lowing  the  “low-level”  approach  is  that  administration 
hierarchies  can  be  built  “on  the  fly”,  simply  by  delegat¬ 
ing  to  a  new  administrator. 

To  summarize,  our  choice  for  a  low-level  policy  mech¬ 
anism  is  dictated  by: 

1.  Flexibility  in  the  types  of  applications  it  can  sup¬ 
port. 

2.  Efficiency  in  evaluating  policy. 

3.  Ability  to  naturally  and  efficiently  express  and  han¬ 
dle  delegation  of  authority. 

4.  Simplicity,  as  a  desirable  property  of  any  system1 2 3 4. 

“To  paraphrase  Albert  Einstein,  “every  system  should  be  as  simple 


3.4  Policy  Updates  and  Revocation 

In  a  credential-based  access  control  system,  adding  a  new 
user  or  granting  more  privileges  to  an  existing  user  in  a 
credential-based  system  is  simply  a  matter  of  issuing  a 
new  credential  (note  that  both  operations  are  equivalent 
in  terms  of  sequence  of  operations  in  our  system). 

The  inverse  operation,  removing  a  user  or  revoking  is¬ 
sued  privilege,  means  notifying  entities  that  might  try  to 
use  the  relevant  credential  that  it  is  no  longer  valid,  even 
though  the  credential  itself  has  not  expired.  Potential  rea¬ 
sons  for  the  revocation  include  theft  or  loss  of  the  admin¬ 
istrator  key  used  to  sign  the  credential  (in  which  case,  all 
certificates  signed  by  that  key  need  to  be  revoked),  theft 
or  loss  of  the  user  or  administrator  key  authority  has  been 
delegated  to,  or  discovery  that  the  information  contained 
in  the  certificate  has  become  inaccurate. 

There  are  four  main  mechanisms  for  certificate  revo¬ 
cation: 

1.  The  validity  period  of  the  credential  itself;  if  it  is  set 
to  a  sufficiently  small  value,  then  the  window  of  revo¬ 
cation  is  effectively  limited  to  that.  On  the  other  hand, 
a  short  lifetime  means  that  the  a  user’s  credential  has  to 
be  re-issued  much  more  often,  which  implies  increased 
work  for  the  administrator  (in  terms  of  credential  gener¬ 
ation  and  distribution).  In  the  extreme  case,  where  cre¬ 
dentials  are  made  valid  for  a  few  minutes  only,  the  CA 
is  effectively  involved  in  (almost)  every  authentication 
protocol  exchange.  This  approach  works  well  when  cre¬ 
dentials  are  used  in  a  transient  manner  (e.g.,  to  authorize 
temporary  access  to  a  resource).  On  the  other  hand,  if 

as  possible,  but  no  more.” 
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credential  revocation  is  rare  in  a  given  deployed  system, 
the  amount  of  unnecessary  work  done  by  the  system  (re¬ 
issuing  short  lived  policy  statements)  can  be  quite  high. 

2.  Certificate  revocation  lists  (CRLs),  and  their  vari¬ 
ants.  The  idea  is  that  the  administrator  compiles  a  list 
of  credentials  that  must  be  revoked,  and  distributes  this 
to  the  enforcement  points  (or,  as  is  more  typical,  the 
enforcement  points  periodically  retrieve  the  list  from  a 
repository).  The  CRL  is  signed  by  the  administrator,  and 
contains  a  timestamp.  An  enforcement  point  can  verify 
that  it  has  received  a  valid  and  reasonably  recent  copy 
of  the  CRL  by  verifying  the  signature  and  examining  the 
timestamp.  Revoked  credentials  can  be  removed  from 
the  CRL  as  soon  as  their  validity  period  expires.  This 
approach  works  well  when,  on  the  average,  only  a  small 
number  of  credentials  are  revoked.  Various  approaches, 
such  as  Delta-CRLs  or  Windowed  Revocation,  attempt 
to  address  scalability  issues  with  this  approach. 

3.  Refresher  credentials.  In  this  scheme,  the  owner  of  a 
long-lived  credential  has  to  periodically  retrieve  a  short¬ 
lived  credential  that  must  be  used  in  conjunction  with 
the  long-lived  one.  They  can  do  this  by  simply  con¬ 
tacting  the  issuer  of  the  credential  (or  some  other  entity 
that  handles  refresher  credentials).  The  advantage  of  this 
approach  over  direct  short-lived  credentials  is  that  a  re¬ 
fresher  credential  is  only  issued  if  the  user  actually  needs 
one.  On  the  other  hand,  it  requires  some  communication 
on  the  part  of  the  credential  owner  (as  do  all  revocation 
schemes,  except  lifetime-based  revocation). 

4.  Online  certificate-status  protocols,  such  as  OCSP, 
have  the  credential  verifier  query  the  credential  issuer 
(or  other  trusted  entity)  about  the  validity  of  a  creden¬ 
tial.  One  drawback  is  that  it  is  the  verifier  that  must  do 
this  status  check;  if  the  verifier  is  a  web  server  or  other 
(potentially  overloaded)  service,  this  approach  places  ad¬ 
ditional  burden  on  it.  On  the  other  hand,  this  approach 
does  not  require  even  roughly  synchronized  clocks,  as 
solutions  (1),  (2),  and  (3)  do.  However,  since  the  ex¬ 
change  needs  to  be  secured,  the  protocol  can  be  fairly 
expensive. 

In  cases  (2),  (3)  and  (4),  the  credential  issuer  (or  other 
trusted  entity)  must  issue  statements  as  to  the  validity  of 
an  issued  credential.  Since  such  statements  must  be  ver¬ 
ifiable,  these  approaches  require  that  this  issuer’s  private 
key  is  available  online  (especially  for  cases  (3)  and  (4)). 
However,  separate  keys  can  be  used  for  issuing  and  re¬ 
voking  credentials;  both  keys  can  be  present  in  the  cre¬ 


dential.  In  the  event  that  the  machine  where  the  revoking 
key  is  stored  is  compromised,  an  attacker  can  extend  the 
lifetime  of  any  issued  credential  that  uses  the  compro¬ 
mised  key  for  revocation  to  its  maximum  validity  period; 
but,  the  attacker  cannot  issue  new  credentials,  nor  can 
they  affect  the  revocation  of  credentials  issued  after  the 
intrusion  has  been  detected  (at  which  point,  a  new  revo¬ 
cation  key  is  used). 

The  decision  as  to  which  revocation  mechanism  to  use 
depends  on  the  specifics  of  the  system;  in  particular,  how 
often  are  credentials  revoked  (and  for  what  reason),  how 
stringent  the  revocation  requirements  are,  what  the  com¬ 
munication  and  processing  costs  and  capabilities  are,  etc. 
For  environments  where  quick  revocation  is  not  neces¬ 
sary,  time-based  expiration  may  be  sufficient;  at  the  other 
end  of  the  spectrum,  a  certificate  status  check  protocol 
may  be  used  to  provide  near  real-time  revocation  ser¬ 
vices.  (Note  however  that  even  Kerberos  uses  an  8-hour 
window  of  revocation,  by  issuing  tickets  that  are  valid  for 
that  long,  as  a  tradeoff  between  efficiency  and  security.) 
Luckily,  the  exact  revocation  requirements  for  any  partic¬ 
ular  credential  can  be  encoded  in  the  credential  itself;  so 
an  administrator’s  credentials  may  require  an  online  sta¬ 
tus  check  for  every  use,  whereas  a  user’s  revocation  re¬ 
quirements  may  be  considerably  more  lax.  Furthermore, 
these  requirements  can  change  over  time  (with  each  new 
version  of  the  credential  that  is  issued). 


4  Conclusions 

The  use  of  credentials  has  many  attractive  properties  in 
terms  of  flexibility.  Yet,  as  in  other  systems,  the  schemes 
for  distributing  them  are  important  to  the  overall  scalabil¬ 
ity  and  correctness  of  the  system.  The  use  of  caches  cre¬ 
ates  some  challenges  for  credential  revocation,  yet  these 
appear  to  be  addressable  with  a  menu  of  techniques,  the 
choice  of  which  is  dependent  on  particular  system  re¬ 
quirements  for  credential  expiry. 

We  have  outlined  requirements  for  scalability,  and  pro¬ 
vide  a  survey  of  viable  approaches  to  meeting  these  re¬ 
quirements.  Our  belief  is  that  from  this  analysis,  one 
should  definitely  favor  the  flexibility  of  credential-based 
policy  management,  while  using  the  lazy  evaluation  tech¬ 
nique.  Refresher  credentials  have  the  most  appeal  to  us 
in  terms  of  scalability  and  consistency  with  respect  to  the 
rest  of  the  system,  but  may  not  be  “safe”  enough  for  all 
security  applications. 
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